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REMOTE OBSERVATORY ACCESS VIA THE ACTS 


Stephen Horan, Associate Professor and Georghios Georghiou 
Department of Electrical and Computer Engineering 
New Mexico State University 
Las Cruces, NM 88003-0001 

Abstract 

An investigation of the potential for using the ACTS to provide the data distribution network for 
a distributed set of users of an astronomical observatory has been conducted. The investigation 
consisted of gathering the data and interface standards for the ACTS network and the observato- 

instrumentation and telecommunications devices. A simulation based on COMNET was then 
developed to test data transport configurations for real-time suitability. The investigation show 
that the ACTS network should support the real-time requirements and allow for growth m the 
observatory needs for data transport. 


Observer Network 

Modem astronomical observatories are rarely owned by one institution. Rather, they are usually 
funded and operated by consortia of many institutions - often with a national distribution o 
partners. The Apache Point Observatory (APO) is a case in point being owned and operated by 
a consortia of five member universities. What makes the APO truly umque is the fromthe start 
the observatory was designed to have all instrumentation and control segments interface with 
telecommunications and networking ports to allow for distributed real-time data acquisition and 

control. 

The APO member sites are illustrated in Figure 1. The observatory itself is located in south- 
central New Mexico near Sunspot New Mexico and also near NASA’s White Sands Groun 
Terminal. This location is important because the observatory should be within the ACTS 
dedicated spot beacon for White Sands. Other observer locations include Las Cruces New 
Mexico Chicago Illinois, Princeton New Jersey, and Seattle and Pullman Washington. With 
the distributed data philosophy, users do not come to the New Mexico observatory location. 
Rather, the observer stays at the home institution and the data is delivered over a telecommuni- 
cations network to a desk-top computer, in this case a MAC H. The observer then controls the 
telescope pointing in real-time and the data is delivered in a timely, periodic manner. 

There are two present modes whereby data can be exchanged between the APO and the observ- 
ers* commercial phone lines, and the Internet. Commercial telephone service is not desirable 
because of expense and available bandwidth for instrumentation data. Internet has the available 
bandwidth but not the delivery guarantees for real-time operations. Because of these two 
constraints, a communications satellite link seemed to have desirable properties for exploitation. 


ACTS Simulation Model 


In order to determine if the ACTS would make a suitable data transport delivery mechanism, 
a simulation model of the end-to-end observatory data network was developed. This would 
include the spacecraft data transport and ground terminal interfaces as well as the computers in 
the observatory. Important issues to deal with were 

(a) could real-time tracking and control information be delivered to the user in a regular manner , 

(b) would real-time data from the instrumentation be delivered prior to the next instrumentation 

data dump, and 

(c) would there need to be excessive data buffering at any point within the network. 

Because the observer would not be physically co-located with the telescope and would only 
communicate through a computer interface, a means to give some form of feedback of the 
observatory conditions is needed regardless of where the observer is physically located. It was 
determined that a simulation model to estimate the data delivery times and buffering require- 
ments would go a long way, prior to satellite launch, to provide the observatory planners with 
the required data to determine if the user interface under development would be adequate. 


Model Elements 

The basic elements to be modeled are illustrated in Figure 2 with the details of the APO network 
given in Figure 3. The ACTS TDMA frame structure used is that given in [1]. The T-l VSAT 
interface parameters are those given in [2]. The ACTS data propagation details through the 
spacecraft are those given in [1] and [2], For the observatory telecommunications links, the 
standard ETHERNET and T-l interface protocols were used. The simulation was configured 
as a datagram service which means that each node in the ground network needed to perform 
routing decisions on the individual data packets. As mentioned above, the actual satellite link 
was modeled as a slotted Aloha link between the ACTS and the source ground terminal then as 
a point-to-point link between the ACTS and the destination ground terminal. This simplification 
allowed the link dynamics to be kept, i.e., waiting for a slot time at the transmitting ground 
terminal, using existing COMNET modeling structures. 


Traffic Model 

The data traffic from the observatory consists of two traffic classes: instrumentation data traffic 
which is of high volume (> 1 Mbit per message) but not with a guaranteed data delivery time 
and housekeeping data which is of low volume but with guaranteed data delivery time. The data 
traffic is summarized in Table 1. For the simulation runs, no return traffic from the user remote 
terminal was used. This would be low-rate, housekeeping-type traffic that would not stress the 
link parameters and would be nearly invisible when compared with the APO side of the link. 



Table 1. APO Data Traffic Model 

Source 

Sensor 

Max Size (bits) 

Rate 

Camera -1 

CCD 

4,194,304.00 

1/min - 1/hour 

Camera-2 

CCD 

67,108,864.00 

1/min - 1/hour 

Camera-3 

CCD 

268,435,456.00 

1/min - 1/hour 

2.5-m survey 

CCD 

2,013,265,920.00 

1 Mbps - 5 Mbps 

Housekeeping 

Tracking 

131,072.00 

1/min 


Pointing 

1,024.00 

1/min 


Status 

1,024.00 

1/min | 


COM NET Simulation 

The method chosen to model the data network was to use the simulation package COMNET 
distributed by CACI [3]. COMNET is a general telecommunications modeling tool which can 
be used for modeling datagram, virtual circuit and call circuit networks. COMNET is written 
in Simscript and available for a number of host platforms. This makes the model transportable 
for other users or for running at different simulation facilities. The simulation model used here, 
employed the datagram components for modeling the transmission of the data. Within the 
modeling package, the user needs to define the following types of parameters by making appro- 
priate entries in menus presented by the simulation package: 


a) data message interarrival time and size, 

b) transport-level protocol PDU size (including overhead), 

c) data link parameters (transmission speed, propagation delay, etc.), and 

d) data link level PDU size (including overhead). 


Hie interaction between the data message (instrumentation or tracking messages) is illustrated 
in Figure 4. COMNET produces the data message of the user-specified size at the user-specitied 
interarrival time. Because os the nature of astronomical observation, these were of fixed size 
and interarrival time. In principle, these could both be statistical variables drawn from a 
probability distribution. 


The various links used in the model represented both the internal data links (ETHERNET local 
area networks) and the satellite Time Division Multiple Access (TDMA) frame. When standard 
frame sizes were encountered as in the LANs, those frame sizes were used for die Da 
PDU The satellite link was more of a challenge since COMNET does not have a TDMA frame 
structure built in, we used the internal Slotted Aloha network to model the TDMA structure. 
Figure 5 illustrates how the link PDU is configured. 


























Figure 6 illustrates the end-to-end COMNET model for the data transport network. Included 
within all of the links are the individual PDU size, link speed, propagation time, and protocol 
details. 


NMSU Simulation Laboratory 

The simulations were developed and run at the Computer Aided Design and Simulation Labora- 
tory at NMSU. VAX workstations were used to run the actual COMNET package. The lab is 
composed of five (5) VAXstation 3100 workstations networked to one VAXserver 3800 with 2.2 
GBytes of disk space, and a LN-03+ printer. The computers run VMS version 5.4 and have a 
variety of high-level language support in addition to the simulation packages. 


Results 

Typical results obtained with COMNET for the APO data network, including using the ACTS, 
are given in Figures 7 though 10. Figure 7 shows the network throughput as a function of 
message interarrival time for three sizes of message traffic. Notice that the trend is not entirely 
linear and for some values of the data packet size, larger throughput can be obtained than with 
larger data packets. Figure 8 gives the end-to-end message delay as a function of packet size 
for differing initial message sizes. Again, a smaller-than-maximum packet size will yield better 
performance than will the largest packet size available. Both of these results show the effect of 
internal data link message sizes affecting the overall characteristics. 

COMNET can also be used for analyzing resources. Figure 9 shows the percentage of allocated 
buffering capacity utilized as a function of packet size. Figure 10 shows what percentage of 
packets undergo blocking at some point as a function of initial message size and packet size. 

All of these results are derived from typical model run data. The value in COMNET lies in its 
ability for us to perform "what if" experiments to change traffic loads, interanival times, and 
protocol details and see what effects are propagated to the output. Since the observatory is 
contemplating the addition of new telescopes to the mountain, this model allows us to easily add 
that new load and check for throughput changes. 


Conclusions 

The need to transport real-time data around the CONUS is a need which users are beginning to 
demand. The astronomical observatory makes an excellent test bed for these concepts. Prior 
to the launch of the ACTS we have modeled the expected data links and protocol interfaces for 
such a network. The traffic driving the network came from two types of sources: high-rate, 
low-volume immediate data and lower-rate, high-volume less immediate data. The ACTS 
system appears to have the capacity to provide both real-time command and control data 
transport as well as bulk data transport with acceptable delays for both types of data. The 
COMNET simulation package allows for us to model varying network loads and configurations 



without major modeling re-workings. 


References 

[1] NASA, Experiments Applications Guide, NASA TM-100265, Lewis Research Center, Cleve- 

land, OH, January 1990. 

[2] Comsat Laboratories, "Advanced Communications Technology Satellite (ACTS) Ground 

Segment Low Burst Rate TDMA Network Control Performance Specification," ACTS 
A140001, Rev. B, DRD302, October 23, 1990. 

[3] CACI Products Company, COMNET 11.5 User’s Manual, Release 5, CACI Products Compa- 

ny, La Jolla, CA, 1992. 



Figure 1 - APO Partners 



















Figure 6 - End-to-End Comnet Model 





Figure 7 - End-to-End Throughput as a Function of Source Load 
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Figure 8 - End-to-End Message Delay as a Function of Packet Size 








SECTION II. USE OF THE ACTS WITH THE APACHE 

POINT OBSERVATORY 



The Apache Point Observatory Communications Networks 
Apache Point Observatory: 

The Apache Point Observatory (APO) runs a Ethernet (10MHz) local area 
network among the principal operations computers. An Appletalk network 
is used to connect printers and about eight peripheral Macintosh 
computers. A Shiva Fastpath-4 provides gateway services between the 
AppleTalk and Ethernet networks. The observatory presently operates two 
SUN 3/260 machines, one of which is the principal operations computer; it 
is this device which communicates with the individual computers which 
more directly control the telescope, instruments, and other observatory 
systems. The latter group includes Macintoshes of various sorts, 
MicroVaxes, and PC-based machines. 

Remote Connections: 

Apache Point Observatory is currently linked to the institutions of the 
Astrophysical Research Consortium (ARC) and other remote observers via 
the NSFnet backbone. There is a dedicated T1 link between APO and the 
New Mexico State University (NMSU) campus in Las Cruces, New Mexico. 
Connection between NMSU/Las Cruces and the University of New Mexico 
(UNM) in Albuquerque, New Mexico, is via 1/3 of a dedicated T1 line 
supplied by New Mexico Technet. A full T1 line extends from 
UNM/Albuquerque to an NSFnet gateway at UCAR in Boulder, Colorado. The 
NSFnet backbone is presently of T3 capacity. All of the ARC institutions 
but one maintain T1 connections to the NSFnet backbone; Washington State 
University has a 56K connection. 

Sacramento Peak Solar Observatory: 

The National Solar Observatory at Sacramento Peak, New Mexico, (SPO) is 
only two kilometers from Apache Point Observatory. Their external 
communications are presently via a 56K link through APO. They will 
shortly be acquiring a 56K direct link to the Jet Propulsion Laboratory in 
Pasadena, California, with line and associated equipment to be supplied by 
NASA NSInet. The existing 56K APO-to-SPO line and hardware will then be 
used to provide a faster link between the two facilities. This will provide 
alternative back-door communications links for both observatories. 



Reliability: 

The first formal tests of network reliability were performed in July 1989 
at which time the APO-NMSU link was of only 56K capacity. First-try 
connectivity success rate between APO and NMSU was then about 98%. A 
70% rate between APO and Princeton University was the poorest 
performance. These results are based upon large file transfers made at 
random times during the day. The few interruptions were brief. (A one-day 
communications loss did result from the interaction between the T1 fiber 
cable near Albuquerque and an overzealous backhoe operator.) Science 
operations at the observatory began in April 1991 with over 90% of 
operations being conducted remotely. We have had no problems with 
remote operations due to the network being down nor have we had 
problems with slow or noisy connections. 

An ACTS Connection: 

The ACTS Experimenter’s documentation is somewhat vague when 
describing of the options, protocols, and physical connections available to 
the experimenter. It does appear that the simplest method of connecting 
an ACTS earth station to current APO computers and communications 
devices would be to treat the earth station as just another T1 line. The 
only new equipment required at APO (other than the earth station itself) 
would be a new interface board for the Cisco gateway and a CSU/DSU line 
interface. ACTS would then be treated as just another network link 
available to APO users. A shortcoming of this approach is that it would 
limit us to using the Internet protocols. 

An increased capacity might provide the ACTS system with a competitive 
edge over the present (essentially) T1 system with its heavy traffic load. 
This would require more substantial upgrades in the interface electronics 
at both the observatory and the ARC institutions. 

The principal advantage of an ACTS link is that it would allow single hop 
communications between APO and the ARC institutions. The present 
arrangement typically requires about eleven. Transmission times would 
probably be appreciably reduced. On the other hand, the earth stations 
themselves represent hardware systems which must be maintained by 
observatory or institutional personnel whereas the present links are 
largely maintained and supported by others. Moreover, the reliability of 
the ACTS connection cannot be appreciably better than the present value 
of esentially 100 percent. 



External Communications Tests 


Procedures: 

Tests of different link configurations were made by measuring round-trip 
transmission times between Apache Point Observatory and the various 
institutions of the Astrophysical Research Consortium (ARC). This was 
done with the UNIX command “ping.” One hundred individual packets, each 
of 1000 byte length, were sent. The average single-packet round-trip 
travel time was then computed. This was done on three occasions for the 
three different link configurations described in the following section. The 
results, for each ARC institution and for three link configurations, are 
tabulated below under the heading “Transmission Time Results. 


System Configurations: 

Prior to 15 May 1992 the external links between Apache Point Observatory 
and the various institutions consisted of the following segments: 

• A 56K dedicated commercial telephone line between Apache Point 
Observatory and New Mexico State University in Las Cruces, New Mexico. 
This contained twisted-pair, microwave, and fiber-optic components. 

•One-third of a dedicated T1 link was provided between NMSU/Las Cruces 
and the University of New Mexico in Albuquerque, New Mexico, by New 
Mexico Technet. 

•A dedicated T1 line links UNM/Albuquerque and UCAR in Boulder, 

Colorado. 

•Connection to the NSFnet backbone is made at UCAR/Boulder. This 
backbone was T1. 

•With one exception, the universities of the Astrophysical Research 
Consortium are connected to NSFnet with T1 capacity. Washington State 
University has a 56K connection. We also have data for Yerkes Observatory 
which is connected to NSFnet by way of a 56K link to the University of 

Chicago. 

Results for this initial configuration are given in the column headed 
“56K/T1" in the table. 


The Apache Point to NMSU link was upgraded to full T1 capacity in mid- 
May of 1992. At this point the principal “bottleneck" in terms of line 
capacity was the 1/3 T1 connection between NMSU/Las Cruces and 
UNM/Albuquerque for most institutions and the 56K link for WSU and 
Yerkes. Times for this upgraded configuration are in the column headed 
“T1/T1” in the table. 

The NSFnet backbone was upgraded to T3 in late May, 1992. Subsequent 
transmission time tests gave the results included in the table under the 
column headed “T1/T3.” The present capacity bottlenecks in the 
configuration are the 56K segments for Washington State University and 
Yerkes Observatory or the 1/3 T1 NMSU/Las Cruces-to-UNM/Albuquerque 
connection for the other institutions. This last link is scheduled to be 
upgraded to full T1 capacity in late summer 1992. 


Transmission Time Results: 


University 
/Machine Addressl 

Average Round-Trip Time (ms) 

56K/T1 T1/T1 I1ZI2 

University of Chicago 
(oddjob.uchicago.edu) 

572 

259 

121 

University of Washington 

601 

295 

332 

(phast.phys.washington.edu) 




Princeton University 
(astro.princeton.edu) 

611 

363 

148 

New Mexico State University 
(hubble.nmsu.edu) 

327 

40 

30 

Washington State University 
(beta.math.wsu.edu) 

925 

929 

645 

Yerkes Observatory 
(otto.yerkes.uchicago.edu) 

882 

602 

446 


Analysis: 

The three sets of measurements were made at different times so the 
tabulated results reflect not only line capacities but also the effect of 
traffic levels at the time of the tests. The Apache Point-to-NMSU link, for 
example, does not make use of the NSFnet backbone so the difference 
between the tabulated 40ms and 30ms entries for NMSU is largely 
attributable to traffic differences over the APO-to-NMSU T1 line. 

However, certain general trends are apparent: 

The first upgrade, of the APO-to-NMSU link from 56K to T1, gave a major 
improvement for traffic to NMSU. The improvement factor for those other 
institutions with T1 connections to the NSFnet backbone was about a 
factor of two. This was not as great as for NMSU since the configuration 
linking these institutions was at least partly limited by the 1/3 capacity 
T1 NMSU-to-UNM link (plus traffic level effects on subsequent segments). 
We anticipate transmission times might be reduced by as much as 50% 
once this segment is upgraded to full T1 capacity. 

The NSFnet backbone is heavily used and its upgrade from T1 to T3 
produced reductions of roughly 40% in typical transmission times. This 
was true even for those connections with a final 56K connection. 



APO User Interface 


We have implemented a Graphical User Interface (GUI) to the Apache Point 
Observatory on a Macintosh computer. Figure 1 shows a particular layout of the 
Macintosh GUI currently used for APO. Shown are the telescope status display, the 
telescope control panel, the CCD camera control panel, a returned image and its his- 
togram, a satellite image, a UNIX-like ‘talk’ window, and a source selection window. 
Thumbwheel controls accept both typed or mouse driven entries; menu selections open 
up alternate windows and configuration dialogs, select instruments, and handle image 
storage and retrieval; control buttons, when clicked on by the mouse driven cursor, issue 
the appropriate commands (in protocol) to the MC. Each user may uniquely configure 
the layout to fit his screen space, save frequently used settings, and store the 
configuration into a personal file. In this manner the same program may be molded to fit 
most users’ preferences. 

On-line help is available for most functions in the form of Apple s Balloon Help 
facility. 


Figure 1. The APO User Interface 

Figure 2 shows the telescope display and control panels. The Telescope Position 
graph in the upper right displays the current position of the telescope as a dark circle in an 
altitude and azim uth polar plot. As an example of how the GUI gives continual feedback 
during a telescope move, consider the case in which the user has entered a coordinate in 
the lower left thumbwheel boxes. The destination position of the telescope appears as a 
gray circle. After the user hits the ‘slew’ button, the timer in right of the display counts 
down to show the time remaining for the move and the dark circle gradually moves to the 
destination position of the gray circle. In this manner the user is kept informed while the 

entire telescope and enclosure rotate to the desired location. 
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Figure 2. The Telescope Control Panels 

Various camera functions may be selected and executed using the CCD camera 
control panel shown in Figure 3. Like the telescope panels, the user is kept informed 
during an operation: the figure shows that 22 seconds have elapsed into an exposure, 
with the circular ‘clock’ ticking away as well as the digits in the elapsed time display. 



Figure 3. The CCD Camera Control Panel 
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Figure 4. The Focus Configuration Dialog Window 


Certain type of orchestrated commands, those that require actions by several 
instruments, are set up using dialog windows. Figure 4 shows the example of a Focus 
command coniguration. Here six exposures will be taken at sue different focus s f^g s * 
starting at -300 and incrementing by 100 for each exposure. The CCD chip will be read 
out at the end, so a multiple exposure of the six images will be saved to disk as 
‘myFocus.’ The telescope initially offsets by -40 arc seconds, and moves 15 arc seconds 
for each exposure. When the focus command is finally issued to the telescope, the 
information included in this dialog will be used to create the appropriate string of 
commands. 


This interface has grown out of several predecessors developed to investigate h 
I’s may be applied to a telescience environment. 1 * 2 In all implementations. 


:how 

GUI’s may be applied to a telescience environment 1 *^ in all implementations, the 
interfaces have reduced learning time and casual users are brought up to speed very 
quickly. In evaluating these previous interfaces and the one outlined here, we have 
identified certain requirements that we feel are desirable. 






1. Easy to learn and use 

2. Intuitive and obvious 

3. As modeless an environment as possible 3 

4. Timely and meaningful feedback 

5. Audible as well as visual cues 

6. Minimal required keyboard use 

7. Control Panel Simulation within a GUI 

8. Keep things uncluttered 

The GUI can create a direct analog to the real device that one is controlling. This 
type of representation aids the user in thinking about the device and its actions rather than 
a program and its actions. In addition to being easier to learn and use than a command 
language, the GUI also reduces the amount of typing required. Typing a command, par- 
ticularly one that is long, requires knowledge of the language and syntax, as well as an 
extra thought process to translate what is to be done into words; also there is always the 
risk of typographical errors. For power users, the GUI has a facility where any command 
may be typed in the UCL if so desired. 

Displaying too much information can be confusing. Rather than supplying all ste- 
ms of all subsystems, only that information which is necessary should be displayed. If a 
warning situation occurs, an alert window with an audible alarm could be automatically 
brought up to explain the situation. 

The Macintosh GUI provides quick-look, simple methods of data assessment and 
reduction. More complex reductions can continue in parallel using other hardware 
(VAX, SUN, etc.) and software (IRAF, AIPS, SAOIMAGE, etc.). As images are re- 
turned to the Macintosh, they may be routed over a local ethemet to the date reduction 
computer, they may be simultaneously FTP’d from the site, or they may be sent from the 
site at a later time. 

The software is an evolving entity and certain aspects of the GUI will 
undoubtedly change to address the various users’ suggestions as we learn how the tele- 
scope and instruments are best used in a remote situation. 

References: 
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Remote Observations at APQ 


Kurt S. J. Anderson 
4 June 1992 


li STANDARD HARDWARE _ . , ... 

The standard hardware at a remote observing facility consists of a Macintosh II computer with 
one or two monitors for display. The computer will usually be in communication with the 
system at Apache Point Observatory through the NSFnet backbone. The connnection at the 
observatory is through the machine named kepler . Its address is kepler.apo.nmsu.edu 


The Master Computer (MC), kepler, is a SUN 3/260 which speaks to the Telescope Control 
Computer (TCC, a Micro Vax) and the various Instrument Control Computers (ICC’s). The ICC 
for the High Resolution Imager, for example, is a Macintosh II. 


It is assumed that the user is familiar with basic aspects of the Macintosh interface, 
particularly mouse/cursor operations such as selection by clicking, opening by double- 
clicking, click-and-drag operations for moving windows and icons, traversing menus and sub- 
menus, and the like. Window are rendered active by clicking on them and many are provided 
with a close box. Windows with title bars can be moved to convenient locations on the screen 
by clicking and dragging. Many windows of the remote interface are provided with Help 
buttons; additional information can be obtained by invoking the Balloon Help facility of 
System 7.0. Beginning users of the remote observing interface are strongly encouraged to 

make use of these aids. 


2l LOGGING Qfl REMQT ELX 


bV 09 M 'o wii . . . 

First contact the observer/operator at the site for observatory status information and tor 
permission to to log on remotely. It might be wise to ensure that no one else is connected. 
The observer/operator must, in any case perform certain tasks such as opening the enclosure 
before you can begin observing. When your Macintosh is booted up, double-click on the 
icon corresponding to the latest version of the remote observing program. It is currently 
“Remark 1 .80". This will presumably reside in a remote observing file of some sort on your 
Macintosh hard disk. The menu bar across the top of the screen should then read: 

4 File Edit Telescope Instruments 
(If it reads something else just click on one of the displayed windows) 

A number of windows should appear on your monitor below this menu bar. 

>a TELESCOPE POSITION window gives right ascension (RA), declination (DEC), hour 
angle (HA), sidereal time (ST), and air mass. The window includes a graphic display of 
telescope position. The epoch of the equatorial coordinates plus current values of altitude, 
azimuth, zenith angle, and image rotator angle are also shown. 


>a SLEW CONTROL window into which you will enter positional information, set image 
rotator angle, and from which you will issue commands to move the telescope. 

>a TESTER “paddle” with various commands on it. This is a temporary feature. It is 
principally used is to request the display of images stored on disk. Time updates can also be 
requested; responses are displayed in the DEBUG window. 

>a DEBUG window in which debugging information will be printed if a program problem 
arises. This window also contains information about program options which you may have 
selected and gives requested update information on times, weather, position, etc. 

Opening Communications 

In order to start the observing session, you need to open communications with the Master 
Computer. Move the cursor to the File menu and hold the mouse button down. Drag the 
cursor down to Communications... and then release the mouse button. (Alternatively, 
simply type #U). In the dialog window that appears you may insert your User Name. The 
buttons for Network and MC Main should be ‘on’ while those for Modem and MC 
Backup should be 'off'. Now click the Hang Up button; in the TRANSCRIPT box you 
should see the message: 

The specified TCP stream is not open 

Now click the Connect button. You should get the following responses: 

reconnecting 

reconnecting 

me establishing callback connection 
ok, you're connected 

An audible tone accompanies the last line. At this point you should click the OK button. The 
dialog window will vanish, and a window will appear giving current warnings and 
observatory status informations. This can be closed with its OK button. 

If connection fails, you might get messages like: 

The network came up halfway and died. 

The net might be down. 

If this happens, try Hang Up followed by Connect again. If this does not work, try quitting 
the remote program and restarting it. It is generally a good idea to begin any reconnection 
attempts with a Hang Up request, particularly if communications were interrupted by a crash 
of the remote Macintosh. It this also fails, call the observer/operator for assistance. 



Subscriptions & Sequences 

You should now subscribe to the various message windows. To do this, pull down the menu 
under the File heading and choose the Messages and Monitor options under the 
Subscriptions menu item. Two new windows with these names will appear. (Windows with 
title bars can be dragged to convenient locations on your monitor with the mouse and cursor.) 

You may talk to other users or to the on-site observer using the MESSAGES window. To do 
so, move the cursor to the window, click, and then type your message with a <return>. A 
“beep” will indicate that the message was sent; a copy will appear in the bottom half of the 
MESSAGE window. Incoming messages will appear here. (Both can also be read in the 
MONITOR window.) 

The MONITOR window displays a text version of the commands (or messages) you issue 
from the interface. 


You may also have certain time-varying parameters updated regularly. To accomplish this, 
go to the Sequences... entry under the File menu. A DATA TIME SEQUENCES window 
will appear. You may choose to have any of the items in this window (Weather, Guide 
Images, Time, Position) regularly updated by clicking on their corresponding boxes. For 
each entry you select a box will appear into which you should insert an update interval. 


2i CONTROLLING THE TELES COPE 

Moving the Telescope 

The items under the Telescope menu are: 

Slew Control 
Offset Control 
Tweaker 
Special Moves> 


Get Catalog- 


Star Plots 

Either Slew Control or Offset Control will be selected, as indicated by a check mark, 
and the corresponding SLEW CONTROL or OFFSET CONTROL window will be opened. 
(You can also switch between these windows by clicking on the small boxes in their upper 

left-hand corners.) 

The SLEW CONTROL window contains boxes for inserting telescope pointing positions, 
setting the focus, and orienting the image rotator. Move the cursor to the window and click to 
make it active. To enter positions, you first choose a coordinate system. A click on the box 


gives you a pop-up menu of choices (FK4, FK5, Geocentric, Engineering). Positions 
(with their epochs) can be entered one of three ways: 

You can use the cursor as a thumbwheel control: Place the cursor just above (or below) the 
digit you wish to raise (or lower). The cursor changes to a downward (or upward) pointing 
arrow when properly positioned. Depress the mouse button to make the indicated digit 
change. (To set thumbwheel speed, go to Preferences under the File menu.) 

2* You can enter values from the keyboard: Select the box by clicking and dragging with the 
mouse and cursor. Type coordinate values using tabs as spacers. A format example for right 
ascension is: HH<tab>MM<tab>SS.S (Subsequent <tab>’s would then move you through 
the corresponding boxes for declination, coordinate epoch, rotator angle, and focus.) 

2* Values can be entered from a previously constructed list: To do this, click Get Catalog 
under the Telescope menu. This gives a SELECT OBJECT window containing a list of 
objects. You may select among alternative lists from this window. An object on the list is then 
picked by clicking on it. A click on the “Apply” button then enters this object s coordinates 
(with epoch) into the SLEW CONTROL window and its name in the Object box of the 
TELESCOPE POSITION window. If you are a confident sort, you can click the “Select” button 
instead; this has the same effect as “Apply” but also causes the SELECT OBJECT window to 
close. The catalog or list is a named text file, with entries in the format: 

object_name<tab>HH<tab>MM<tab)SS.S<tab>dd<tab>mm<tab>ss.s<tab>epoch 

Entries are separated by a <return>. The object_name is any alphanumeric string of 
characters. “HH" and “MM" of the right ascension, and “dd" and"mm" of the declination, are 
integers while” SS.S”, “ss.s", and “epoch” are decimal entries. Only the degrees entry (dd) 
has a sign. 

To point the telescope to the entered coordinates, click the move enable button (it will then 
read move disable) to activate the slew buttons in the SLEW CONTROL window. Then 
click on slew. An indicator in the right of the window will indicate the time required and 
remaining to accomplish the position change. Telescope positioning during the slew will be 
graphically indicated here and in the TELESCOPE POSITION window. When the move is 
completed the coordinates will appear in the TELESCOPE POSITION window and and the 
words “move complete" will be heard. 

Note that the Main Computer (MC) updates catalog coordinates to the present epoch. 

Focus and image rotator angle can also be set from the SLEW CONTROL window. Desired 
values can either be typed directly into the appropriate boxes, after selecting the box with the 
cursor and mouse, or by using the cursor as a thumbwheel control. Rotator angle can be in 
either Object or Horizon coordinates; the box just below the word Rotate indicates the 
implementation. A pop-up menu appears when you click on this box and permits you to 
switch between these options. With the Object option the instrument rotates to maintain a 
fixed orientation with respect to equatorial coordinates as projected on the plane of the sky. In 



Horizon the instrument orientation is fixed in angle with respect to the horizon. Normally 
one uses Object-based rotation for imaging. Horizon might be used in spectroscopy to 
place the atmospheric dispersion along the slit. 

Checking the Calibrate box in the SLEW CONTROL window causes the telescope to move 
to an FK5 star close to the desired final position, center it, establish a coordinate correction, 
and then go to the desired position with that correction applied. 

Finally, clicking the Where box in the SLEW CONTROL window updates the quantities 
displayed on the TELESCOPE POSITON window. 


Selecting Offset Control under the Telescope menu, or clicking the small box in the 
SLEW CONTROLwindow, gives the OFFSET CONTROL window. In this window the user can 
offset the telescope's position from the coordinates given in the SLEW CONTROL window. 
The type of offset may be object coordinates (in right ascension and declination) or 
instrumental coordinates (X and Y on the HRI detector, for example). The offset type is 
selected from a pop-up menu that appears when one clicks on the Offset Type box and is 
indicated in that box. Offsets in equatorial coordinates are in seconds of arc both for right 
ascension (RA) and for declination (Dec). Positive offsets correspond to motions eastward 
and northward on the sky, respectively. The X and Y offsets in instrumental coordinates 
depend on the instrument. For the HRI they correspond to motions along rows and columns, 
respectively, on the CCD chip. These motions are also measured in arcseconds. To apply 
the specified offset, click on the offset box. 

Offsets can be absolute (abs) or relative (rel) depending upon which of these buttons is “on”. 
Absolute offsets are always relative to the reference position given in the SLEW CONTROL 
window. If you request/apply the same absolute offset a second time, the telescope will not 
move since it has already applied that offset to the reference position. Each request for a 
relative offset, on the other hand, moves the telescope the specified offset amount from its 
present position, whatever the original reference position. This feature is used if you wish to 
move stepwise off in some direction in sky or instrument coordinates. The actual pointing 
direction of the telescope, including offsets, is always given as Current Position in the 
TELESCOPE POSITION window. This is updated after every motion. The reference position 
is always given in the SLEW CONTROL window. 

The Tweaker can be selected from the Telescope menu. It acts like a manual “slow 
motion" paddle. As long as the mouse button is held down in in one of eight particular 
directions, the telescope will move in that direction at a constant velocity . This feature is not 
. intended to be used remotely, since there is no visual feedback. 



Selecting Special Moves under the Telescope menu produces a sub-menu with three 
selections. They are: 

>Move To nearby FK5 Star: The telescope does just that. An examination of the field can 
then be used to give pointing accuracy information. 

>Recalibrate: Moves to a nearby FK5 star, centers, determines coordinate corrections, and 
then returns to the previous coordinate setting having applied the correction. This correction 
is retained in subsequent moves of the telescope. 

>Home Telescope: This moves the telescope to its parked position, (azimuth =100.8°, 
elevation=+6.0°). An audible "move complete" indicates the telescope has successfully 
homed.. 


CHOOSING AND OPERATING AN INSTRUMENT 
Instrument Choice 

The Instruments menu offers the following selection: 

HRI 

Echelle 

GRIM 


Guider 


Weather Window 

At present, only the first and last of these are implemented. Selecting Weather Window 
produces a small window which gives current weather information. This can be updated by 
clicking the appropriate box or can be set to update automatically at regular intervals. 


The High Resolution Imager (HRI) 

Go to the Instruments menu and select HRI. A new entry, HRI, will appear on the menu 
bar. Under it you will find: 

Camera Control 


Filters... 
Exposure... 
Focus... 
Image Xfer... 



Camera control a , . . s 

A click on Camera Control will give you the HRI CAMERA window . Into this window you 
can enter a File Name for the image. There is also space for a Comment which will go in 
the resulting image header. In this window you also select the type of exposure, and the 
exposure time. One box gives the status of your exposure (once you've initiated it) while 
another tells you which filter is in place. 

Exposure Time . 

Exposure time is set using the Dial-A-Time boxes; the format is hh mm ss.s. Times can be 

entered in three ways. First, you can use the boxes as a cursor-operated thumbwheel (as 
was done for setting telescope coordinates). Second, you can enter a time from the 
keyboard, using <tab> to move from hours to minutes to seconds. Third, you can select from a 
list of five preset integration times. To do this, click on the Preset box and make your 
selection from the resulting pop-up menu. Selecting the last entry in this menu, Set 
Presets..., gives another window within which you can alter the choices of preset times. 


Exposure Type . 

Clicking on the Function box results in a pop-up menu offering the following choices: 


Expose 

Focus 

Dark 

Flush 

Flat 

Send 

Only the first three are highlighted and available. 

Expose starts the exposure sequence with a preset number of flushes of the chip. The 
shutter is opened for the preset exposure time then closed. The image is then read out. 
Various conditions on the exposure and subsequent processing of the image are set using 
the window obtained by selecting Exposure... from the HRI menu. See below. 

Focus initiates a series of exposures, at the preset exposure time, accompanied by motions 
of the telescope and changes in the focus setting. Images on the resulting multiple exposure 
can then be examined to select the best focus. The details of telescope offsets, focus steps, 
and the like, are set in the window obtained by selecting Focus... from the HRI menu. 
Again, see below. 

Dark is identical to Expose except the shutter is not opened. This option is used to get 
frames from which the dark count and bias levels can be ascertained 



Selecting Filters... from the HRI menu gives a SELECT FILTER window describing the filter 
choices available. A Help box explains the various command options. Ordinarily you would 
Re-lnit (reinitialize) the filter controller only at the beginning of your run and an Update 
wouldn’t be required unless you changed filter sets subsequently. Reset is used only when 
something gets hopelessly fouled up. Usually all you have to do to implement your filter is to 
click the appropriate filter’s button and then the Move box. The filter presently in place is also 
indicated in the HRI CAMERA window. 


In the CONFIGURE EXPOSURES window, obtained from selecting Exposure... under the 
HRI menu, you set the principal characteristics of the exposure and the reduction steps 
which might be applied to the image(s). Only the exposure time and the shutter opening 
decision are controlled elsewhere (the HRI CAMERA window). The quantities set are: 

>Save Image As... This is the name of the output image(s). For multiple images^ a^ 
numerical suffix is added to the name you provide in the format “name.l", “name. 2 , name. 3 , 
etc. This is true for processed images such as means and medians as well. The last image 
name used is saved as the default name (with incremented numerical suffix) for the next 
image if no changes are made to the CONFIGURE EXPOSURES window entries. The name 
inserted here appears in the CAMERA CONTROL window, and vice-versa. 

>Number of Exposures This is the number of (identical) exposures that will be made and 
used for any subsequent processing. 

>Number of Flushes This is the number of flushes performed before each exposure. A 
flush is a readout of the chip to clear the pixels and registers. This image is discarded. 

>Binning These are the on-chip binning options. Only the 1x1 and 2x2 options are 
implemented in the HRI. 

>Bias Image (from disk)... This is the name of an image from the MC disk which will be 
subtracted froml images if debias is selected from among the Reduction choices 

>Flat Field (from disk)... This is the name of an image from the MC disk by which images 
will be divided if flatfield is selected from among the Reduction choices. I f debias is 
also selected, its subtraction will be performed first. 

>FITS Comment... A comment entered here will be included as part of the FITS header. 
>Reduction Choices 

There are a number of reduction choices which can be applied to individual images of a 
series as well as to final images derived from the individual images. These choices are: 

♦median : computes the median on a pixel-by-pixel basis for a sequence of n images. At least 
three images are necessary. The median is saved as the last image, numbered n+1 . 



♦ averag e: computes the average of n images on a pixel-by-pixel basis and saves the 
result as the (n+1 )- st image. 

♦debias : subtracts the named bias frame stored on disk from the indicated images. The 
resultant image replaces the original. 

♦flatfield : divides the indicated images by the named flat field frame stored on disk. The 
resultant image replaces the original. This follows bias subtraction if debias is also chosen. 

«Save>Tape: writes the indicated images to tape. Not presently implemented. 

»Send>FTP : forwards the images to the remote user’s address with the ftp protocol. 

♦Send>Mac : sends the indicated images to the remote Macintosh for display. 

Certain combinations are undesirable: You would not, for example want to debias the 
average of a series of images which had been individually debiased. Similarly, if you only 
wish to save the average of a series, it is computationally more efficient to debias or flatfield 
just that final image rather than each of its components. 

Focus.... 

Selection of Focus... gives the CONFIGURE FOCUS window in which you set the 
parameters which will govern the sequence of images taken when you issue the Focus 
command from the HRI CAMERA window. The focussing sequence consists of a number of 
exposures on a single frame. Both the telescope pointing and its focus setting are changed 
between exposures. In the CONFIGURE FOCUS window you can insert an image name in 
the Save Image As... box. You also set: 

># of exposures: Enter the number of exposures in the sequence (usually 6-12) 

>Starting Offset (arc”): The telescope will offset this amount from its initial position 
(presumably centered on your focus star) before making the first exposure. This entry is 
customarily negative. If you are centered, this dimension should be somewhat less than the 
field radius. 

>horizontal/vertical: Choose the focus star image to translate either horizontally or 
vertically on the detector display between exposures of the focus sequence. 

>Telescope Step Size (arc”): This is the distance the telescope moves between the 
second and subsequent exposures. The motion between first and second exposures is twice 
this value. This entry is generally positive if the starting offset is negtive. 



>set star magnitude: A magnitude for the focus star can be entered in the the right box if 
the left box is checked. A catalog search is performed for a star of similar magnitude in the 
vicinity of the current telescope position. If the search is successful, the star will be used for a 
focus star. This feature is not presently implemented. 

>Start Focus at: Enter the initial focus setting. Under normal circumstances, best focus 
will be within a few hundred units of zero. 

>Step Size: Enter the focus step size. The focus setting will be incremented by this amount 
between exposures. An initial value of 50 tolOO is about right. 

The focus image can be sent to the Macintosh by checking the return Image to Mac box. 
The select best focus option is not yet implemented. 


Selection of Image Xfer gives the TRANSFER SETTINGS window within which one sets 
the parameters governing the transfer of images to the remote Macintosh. You can chose to 
have either 8 or 16 bit images sent. (The TRANSFER SETTINGS window can also be 
summoned by selecting Transfer>Transfer Setlngs under the Images menu.) 

The Shift bits entry indicates the number of the least significant bits which are not sent 

when the 8 bit option is selected. If the Shift bits entry is n, bits 1,2 n are discarded, 

bits n+1, n+2 n+8 are sent, and bits n+9,..,8-n ar e discarded. A value of 6 seems to 

be about right for n. 

Generally Autoblock should be checked, and the delay set at 0.2 seconds. Autoblock 
causes the image to be divided into blocks for transmission and the delay is the interval 
between transmission of the blocks. The intent is to avoid problems caused by limited line 
capacity and/or traffic congestion. 

If you only wish to transfer part of the image, check Sub frame. Boxes will then be 
highlighted into which you can insert coordinate values which define the rectangular 
subimage you wish to send. To avoid grief, make sure that the X lo and Y lo entries are 
smaller than the corresponding X hi and Y high values. These entries are in column 
number for X and row number for Y. 


Si VIEWING IMAGES 


In order to see your images that you’ve taken so far, you can use the TESTER WINDOW. 

Click on Image. This will produce a SELECT FILE window listing the images on the MC 
disk. With the cursor, select the image you want to display then click the select button. The 
image will appear on the Macintosh screen. A histogram of the image will also appear. (If 
not, go to the Instruments menu and select Histogram. See below.) A small COORDS 
window also appears with the displayed image; as the cursor moves over the image this 
window will display cursor coordinates (in detector and sky coordinates) plus the pixel value 
on an 8 bit (0-255) scale. 

Most image display is accomplished using the entries under the Images heading of the 
main menu. These entries and their applications are: 

Load... is used to display and image currently on the Macintosh disk. Selection of Load... 
gives a window listing the available images. Select an image and click Open. 

Save As... saves the current (frontmost) image to the Macintosh disk in its existing bits/pixel 
format. You insert an image name and indicate a save location (i.e. a folder) in the window 
which appears. 

Save As 8 bit...is the same as Save As... except that the image is saved in 8-bit format. 

Fits Comments... provides a window into which you can enter comments which are added 
to the fits header either for the current Macintosh image or for a selected image on the MC 
disk. 

View Fits Header provides a window containing the fits header information for the current 
Macintosh image. If no image is presently opened, a list of available images is presented. 

Transfer> gives four options in a sub-menu. CCD is used to display images from the MC 
disk. Selection is made from a list of available images which appears when this entry is 
selected. Satellite gives a listing of weather satellite images available for display. These are 
stored on the MC and the image names contain the time they were taken. The most recent 
image is the last one listed, stop Transfer is used to abort an image transfer in progress. 
Finally, Transfer Settings...gives the TRANSFER SETTINGS window described earlier. 

Histogram opens a window giving a histogram of pixel values for the current (foremostO 
Macintosh image. By using the scrollbar on the right side of the window you can more clearly 
examine the histogram. The cursor can also be used to drag the vertical dotted lines at either 
side of the histogram to limit the range of pixel values corresponding to the range of display 
intensities. Intensities below the leftmost dotted line are assigned a display value of zero, 
those above the rightmost line a value of 255, and those in between are scaled over the 0- 
255 interval. 



fil TRANSPORTING IMAGES 


The Macintosh images are not in a format suitable for AIPS or IRAF; they are only Macintosh 
readable. The easiest way to get your images down from the site in useable form is to 
employ IRAF to place them into suitable form and then ftp the images to your home institution. 
First you will need to log in to the site ( “kepler.apo.nmsu.edu’') and supply a suitable 
username and password. Once logged on, you start IRAF by typing cl. The following 
command sequence will change your images (named” filename” in the example below) to 
FITS format: 

kepler% cl 

cl>cd /arc/apotop/New/iraf 
cl>dataio 
da>ls 

da>wfits filename filename.fits 
da> logout 
kepler% logout 

You can then FTP to the site and retreive your images in FITS format. You first log onto kepler 
from your machine, with the command “ftp kepler@apo.nmsu.edu" supplying a username 
and password. To get the image named ” filename.fits” requires the commands: 

ftp>cd /arc/apotop/New/iraf 

ftp>binary 

ftp>prompt 

ftp>get filename.fits 

ftp>quit 

(If you are already in kepler you can send the file to your home institution. First ftp your 
machine from kepler and then use “put” or “send” instead of “get”.) 


(to see the list of images stored on disk) 
(to convert image to FITS format) 



